Simon McVittie [Thu, 25 Sep 2025 13:01:25 +0000 (21:01 +0800)]
vulkan: Optionally share one JSON manifest per driver between architectures
If the library_path is just a basename like `libvulkan_lvp.so`, then we
can share the same JSON manifest like `lvp_icd.json` between all of the
architectures, like we already do for Vulkan layers. The library will
be looked up in the dynamic linker's default search path in this case,
and in practice will be found in `${libdir}`. This is how the Mesa's
EGL driver and Vulkan layers work, how Mesa is packaged in Debian 13,
and also how the Nvidia proprietary driver works; it makes installation
simpler for distros, especially on multiarch systems like Debian and
the freedesktop.org SDK.
However, if we want a separate manifest per architecture in order to
be able to write the full path into it, we still need per-architecture
filename disambiguation like `lvp_icd.x86_64.json`.
We presumably still want a separate per architecture on Windows, because
the concept of a single monolithic `${libdir}` is less common there, and
it can also be helpful during development when setting `$VK_DRIVER_FILES`
to force the use of a specific driver installed in a non-default location.
Use the following parameter to passed to vk_icd_gen:
'--icd-lib-path', vulkan_icd_lib_path,
'--icd-filename', icd_file_name,
output : 'virtio_icd.' + vulkan_manifest_suffix,
and the output is passed by '--out', '@OUTPUT@',
so we can detect vulkan_manifest_per_architecture from the --out parameter in script.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13745 Signed-off-by: Simon McVittie <smcv@collabora.com> Co-authored-by: Yonggang Luo <luoyonggang@gmail.com> Reviewed-by: Mel Henning <mhenning@darkrefraction.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37314>
Applied-upstream: 26.0, commit:b860ae309a42dce317d275000016abc2b4ebe687
Gbp-Pq: Name vulkan-Optionally-share-one-JSON-manifest-per-driver-betw.patch
Simon McVittie [Thu, 11 Sep 2025 19:15:25 +0000 (20:15 +0100)]
vulkan: Don't emit library_arch if the library_path is just a basename
If the library_path is just a basename like `libvulkan_lvp.so`, then
we can share the same JSON manifest between all of the architectures,
like we already do for Vulkan layers. This is also how the Nvidia
proprietary driver works, and how Mesa is packaged in Debian 13.
However, this will only work if we don't mark the manifest as being
architecture-specific.
This partially reverts commit f7aa6ba9 "vulkan: Specify library_arch in
ICD files".
Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Mel Henning <mhenning@darkrefraction.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37314>
Applied-upstream: 26.0, commit:1ec7bc382d13f01371a4255004b2fd4f545739a9
Gbp-Pq: Name vulkan-Don-t-emit-library_arch-if-the-library_path-is-jus.patch
Forcing zink explicitly would get zink-on-lvp picked up over llvmpipe
for gbm dri support, which is not intended. Currently, zink_screen's
choose_pdev won't be able to reject it when the driver name is explicit.
So we have to revert the change first to mitigate regressions.
[changes brought forward from 24.0.7-1+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Fri, 24 May 2024 10:55:59 +0000]
* Try to disable valgrind.
* Move valgrind from build-depends to build-conflicts.
Forcing zink explicitly would get zink-on-lvp picked up over llvmpipe
for gbm dri support, which is not intended. Currently, zink_screen's
choose_pdev won't be able to reject it when the driver name is explicit.
So we have to revert the change first to mitigate regressions.
Daniel van Vugt [Fri, 4 Apr 2025 09:41:37 +0000 (17:41 +0800)]
drisw: Avoid crashing when swrast_loader == NULL
This is a blanket fix for all the segfaults in `drisw_init_screen()`
when `swrast_loader` is NULL, since 1de7c86bc1. A similar more targeted
fix for vmwgfx can be found in f3b8d7da46 ("egl: never select swrast
for vmwgfx"). We can safely return NULL because the caller
`driCreateNewScreen3` handles NULL, as does its own callers.
As this is currently the top crasher of gnome-shell since Ubuntu
upgraded to Mesa 25 and it seems to be coming from multiple different
drivers still, we want a universal fix to at least stop the crash
reports. People can figure out which drivers still need tweaking in
`dri2_load_driver` or elsewhere later.
Fixes: 1de7c86bc1 ("dri: pass through a type enum for creating screen instead of driver_extensions")
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12678 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12859 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12300 (nvidia-drm)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12462 (nvidia-drm)
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2101817
Gbp-Pq: Name drisw-Avoid-crashing-when-swrast_loader-NULL.patch
Daniel van Vugt [Fri, 4 Apr 2025 09:41:37 +0000 (17:41 +0800)]
drisw: Avoid crashing when swrast_loader == NULL
This is a blanket fix for all the segfaults in `drisw_init_screen()`
when `swrast_loader` is NULL, since 1de7c86bc1. A similar more targeted
fix for vmwgfx can be found in f3b8d7da46 ("egl: never select swrast
for vmwgfx"). We can safely return NULL because the caller
`driCreateNewScreen3` handles NULL, as does its own callers.
As this is currently the top crasher of gnome-shell since Ubuntu
upgraded to Mesa 25 and it seems to be coming from multiple different
drivers still, we want a universal fix to at least stop the crash
reports. People can figure out which drivers still need tweaking in
`dri2_load_driver` or elsewhere later.
Fixes: 1de7c86bc1 ("dri: pass through a type enum for creating screen instead of driver_extensions")
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12678 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12859 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12300 (nvidia-drm)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12462 (nvidia-drm)
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2101817
Gbp-Pq: Name drisw-Avoid-crashing-when-swrast_loader-NULL.patch
Daniel van Vugt [Fri, 4 Apr 2025 09:41:37 +0000 (17:41 +0800)]
drisw: Avoid crashing when swrast_loader == NULL
This is a blanket fix for all the segfaults in `drisw_init_screen()`
when `swrast_loader` is NULL, since 1de7c86bc1. A similar more targeted
fix for vmwgfx can be found in f3b8d7da46 ("egl: never select swrast
for vmwgfx"). We can safely return NULL because the caller
`driCreateNewScreen3` handles NULL, as does its own callers.
As this is currently the top crasher of gnome-shell since Ubuntu
upgraded to Mesa 25 and it seems to be coming from multiple different
drivers still, we want a universal fix to at least stop the crash
reports. People can figure out which drivers still need tweaking in
`dri2_load_driver` or elsewhere later.
Fixes: 1de7c86bc1 ("dri: pass through a type enum for creating screen instead of driver_extensions")
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12678 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12859 (radeon)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12300 (nvidia-drm)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12462 (nvidia-drm)
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2101817
Gbp-Pq: Name drisw-Avoid-crashing-when-swrast_loader-NULL.patch
projects / mesa.git / log